SD Times Issue 216 by BZ Media

Author:BZ Media
Language: eng
Format: epub
Tags: SD Times;
Published: 2009-02-14T16:00:00+00:00

■"l«M

built, rather than something that's bolted on after the software is developed.

Vi Labs' DeMarines agreed that security needs to be kept in mind throughout the development process. In terms of thinking about the next release as an application is under construction, a tester has the chance to figure out how to make it more resistant to tampering or piracy during the design phase. Testers can use tools that hackers might use to analyze or reverse-engineer an application. This can give the tester a better sense of how sturdy the application is.

"You don't want to be starting to think about testing security as you're coming into a release candidate," DeMarines said. "You want to be looking at this fairly upfront when most of the functionality has been implemented in a way that you can test it, and then figure out how to make it resistant to the kinds of threats the enterprise is worried about."

While there are many products on the market that allow software providers to scan source code for vulnerabilities, and it is important to do so, the key is acquiring the mentality to understand what the threat is and putting that feedback into the design, DeMarines added.

West said that mentality is pretty well ingrained in most developers today, and the enterprise software industry has realized that security needs to be a part of the full process. "There's still a wide range of maturity levels in terms of how close companies are getting to obtaining that Utopia of software being built in at every step, but for the most part, companies are doing whatever they're able to now in order to make that a reality," he said.

POSITIVE VS. NEGATIVE

When attempting to implement security throughout the development process,

Industry figures say proper testing for security requires thinking like an attacker, instilling security into the full development process

occur, which is close to impossible.

Most relevant requirements aren't going to be positive, said West. Some will be redundant because they will tell the tester to avoid obvious vulnerabilities. A requirement like, "An attacker should never be able to take control of an application," is the type of requirement that should be moved away from because it isn't particularly useful. Good security requirements can give clues to testers downstream about what might constitute unintended behavior.

"You could say, for example, the application will never render un-encoded HTML or Javascript," said Fortify s West. "That's something a QA tester with relatively little security knowledge could go into a specific test case and verify. They can submit HTML characters to that page, and when it is displayed back to me, there shouldn't be any shown. That's going to

Additionally, it's not always easy to have all requirements accepted because there can be many more requirements than can fit into a given cycle, Weider said. This results in a "tug of war" as far as what requirements make it into the process. Because of this, testers need to prioritize security improvements to the application in the same way other software professionals prioritize quality and functional improvements.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.